home *** CD-ROM | disk | FTP | other *** search
/ BBS Toolkit / BBS Toolkit.iso / rbbs_pc / rbbsdocs.zip / RBBSDOCS.APH < prev    next >
Text File  |  1990-11-05  |  14KB  |  244 lines
  1.  
  2.  
  3.  
  4.     APPENDIX H -- Running a multiple node RBBS-PC                           H-1
  5.  
  6.  
  7.     APPENDIX H -- Running a multiple node RBBS-PC
  8.     ---------------------------------------------
  9.     Before you consider  running multiple  nodes (i.e. allowing  more than  one
  10.     caller on your BBS at a time), you should already have RBBS-PC working well
  11.     on  one node.   If  you  don't have  your  board running  smoothly with  NO
  12.     crashes, STOP right here and  concentrate on your single-node system.   You
  13.     will  only compound your  errors and frustrate  yourself if you  try to get
  14.     RBBS-PC operating on multiple nodes before you get it operating well on one
  15.     node.
  16.  
  17.     When  configuring a multi-node RBBS-PC, you may  have to make a decision of
  18.     SPEED vs. STORAGE.  In a  LAN environment, accessing data stored on another
  19.     machine  is slow.  Therefore, you may want to keep copies of ALL text files
  20.     on each  machine, and ONLY share  those files that  are mandatory (MESSAGE,
  21.     USER, UPLOAD dirs).  However, to  do this you will have to keep  nearly ALL
  22.     RBBS-PC files  updated on EACH  RBBS-PC machine.   This can  waste storage,
  23.     increase  maintenance hassles, but it does greatly improve performance on a
  24.     LAN.   Other single-machine environments  (such as DESQview,  PC-Slaves) do
  25.     not require you to make this choice.
  26.  
  27.     To  make multi-node  operation  easier,  you may  want  to  put all  "node-
  28.     specific" files in separate directories (i.e. C:\RBBS\NODE1, C:\RBBS\NODE2,
  29.     etc.).   This will reduce  the chances of having  one node overwrite a file
  30.     from another node.   The following example assumes you  have created a NODE
  31.     subdirectory for each node on your system.
  32.  
  33.     There are certain  parameters in the CONFIG utility which  you will want to
  34.     consider adjusting in order to facilitate your multi-node RBBS-PC.
  35.  
  36.     To  begin with, you will  need to make an CONFIG  .DEF description file for
  37.     each node.   Copy the  file RBBS-PC.DEF  to RBBSnPC.DEF, where  "n" is  the
  38.     number for the node (e.g. RBBS1PC.DEF, RBBS2PC.DEF, etc.).  You will need a
  39.     configuration description files for each node, even if it is a "local" node
  40.     without a modem.
  41.  
  42.     When you start the CONFIG utility, you can either specify the configuration
  43.     description file name  after the  CONFIG program name  on the command  line
  44.     (e.g.  CONFIG RBBS1PC.DEF), or you can let  CONFIG ask you whether you will
  45.     be  running multiple  RBBS-PCs,  answer the  question  with "Y",  and  then
  46.     specify the  number of  the node you  wish to  edit (answering "1"  at this
  47.     point would then edit RBBS1PC.DEF).
  48.  
  49.     The CONFIG  parameters that you will probably want to change in your multi-
  50.     node system are as follows:
  51.  
  52.     161  Maximum  number  of concurrent  RBBS-PC's.   Set  this to  the maximum
  53.          number of nodes you will ever run.  Remember that you need to allocate
  54.          space  for your  local nodes,  also.   This  causes more  space to  be
  55.          allocated  in the MESSAGE  files.  You  can change this  number at any
  56.          time, and CONFIG will create the needed room, however the only harm in
  57.          allocating EXTRA nodes is 128 bytes of wasted disk space per node.
  58.  
  59.     162  Environment running  multiple copies.   Select whichever  network type
  60.          describes the environment you are running.   If you have some doubt as
  61.          to which type fits your network, select  NETBIOS (DOS SHARE).  NETBIOS
  62.          is a fairly universal network interface for applications software, and
  63.          most LAN products offer support for it.
  64.  
  65.  
  66.  
  67.     RBBS-PC 17.3A            TECHNICAL REFERENCE MANUAL                     H-2
  68.  
  69.  
  70.     88   System file for recording comments.  You can set  a different comments
  71.          file for each node you are running (NODE1\COMMENTS and NODE2\COMMENTS,
  72.          for example),  but RBBS-PC can allow a single, shared comments file in
  73.          all but the CORVUS network.
  74.  
  75.     90   Caller  log files.   RBBS-PC does NOT  share log  files between nodes.
  76.          Each node  must have a separate log file (NODE1\CALLERS, etc).  If all
  77.          nodes write to the same  callers file, you will not be  able to figure
  78.          out which node did what!
  79.  
  80.     93   File controlling scan for mail waiting.  If, for some reason, you want
  81.          to have  some conferences or  sub-boards visible on  only one  of your
  82.          nodes,  you  have the  option  of  creating separate  conference  mail
  83.          control  files  (e.g.  NODE1\CONFMAIL.DEF,  NODE2\CONFMAIL.DEF,  etc.)
  84.          This  is certainly not required, however,  and most installations will
  85.          run with identical conference mail control files.
  86.  
  87.     100  File built dynamically to open a  door.  RBBS-PC creates an batch file
  88.          for each  node when dooring.  This  batch file must be  unique for the
  89.          node.  Name yours  NODEn\RCTTY.BAT, where "n" represents the  node you
  90.          are configuring currently.
  91.  
  92.     104  The .BAT file to re-invoke  RBBS-PC.  If you do not make your RBBS.BAT
  93.          file  read-only, you might have problems when several nodes attempt to
  94.          access it  at the same time.   In most  cases, this can be  avoided by
  95.          marking the .BAT file  "READ ONLY," but you may have  to have a unique
  96.          BAT file for each node of RBBS-PC (e.g. RBBS1.BAT, RBBS2.BAT, etc.)
  97.  
  98.     204  Drives available  for downloading.  Make certain  to list not only the
  99.          drives from the computer local to the node, but also the network drive
  100.          letters.    We recommend  using  the  DOS SUBST  command  to make  the
  101.          references  to local drives match those that the remote machine refers
  102.          to them as.  For example,  if the remote machine refers to your  drive
  103.          C: as drive W:, then use the DOS SUBST command and refer to it locally
  104.          as drive W:, also.   It will reduce confusion for you to only refer to
  105.          a  drive by one  name.  Remember,  you can  have up to  15 letters, no
  106.          more.
  107.  
  108.     Now save  these  CONFIG parameters,  and you  will have  a "network  ready"
  109.     configuration description  file.  You can copy this .DEF file for the other
  110.     nodes,  and then change the  node-specific parameters for  each.  Remember,
  111.     each node gets its OWN file!
  112.  
  113.     Remember also that  each node is likely to have a  different modem.  Not in
  114.     ALL  cases, obviously,  but it  justifies a  reminder here.   Let's  take a
  115.     typical example.  On one node, you are using a Hayes 2400 compatible modem,
  116.     and  on  the other  a US  Robotics Courier  HST.   Obviously, the  setup is
  117.     greatly different  between these  two.   It's not  a problem with  RBBS-PC,
  118.     however.    When  you  have  CONFIG  loaded  and  are  editing  the  node's
  119.     configuration description files just remember to put the proper information
  120.     FOR THAT NODE into CONFIG parameters 221 (Comm port), 225  (Modem settings)
  121.     and 231 (Firmware initialization).   Each node can have  a different modem,
  122.     use  a different COM  port, run at  different speeds, or  even use a FOSSIL
  123.     driver or not, and RBBS-PC can easily adjust to it.
  124.  
  125.     AUTOEXEC.BAT
  126.  
  127.     In the AUTOEXEC.BAT file for each node, you will want to  add the following
  128.     environment variables.
  129.  
  130.  
  131.  
  132.     APPENDIX H -- Running a multiple node RBBS-PC                           H-3
  133.  
  134.  
  135.     SET NODE=n (where "n" is the node number)
  136.     SET DSZLOG=XFER-%node%.DEF
  137.  
  138.     There may be other  variables also required by  your individual setup,  but
  139.     the RBBS.BAT  file expects to find  the %node% variable, and  some external
  140.     file transfer protocol drivers  (DSZ, especially) will use the  DSZLOG file
  141.     to pass success-or-fail back to RBBS-PC.  You need a separate one built for
  142.     each node, and this will take care of it.
  143.  
  144.     SUB-BOARDS
  145.  
  146.     If you have sub-boards set up, you will create  a configuration description
  147.     file  for each sub-board.  However, the configuration description file will
  148.     not have  a node number in  its title.  The  configuration description file
  149.     name  will take  the  form  "xxxxxxxC.DEF",  where  "xxxxxxx"  is  the  1-7
  150.     character sub-board name.  For example,  a sub-board named GAMES would have
  151.     a  configuration  description  file named  GAMESC.DEF.    This  is a  major
  152.     difference  from   the  configuration   description  file  for   the  nodes
  153.     themselves.   Each node has its  own file, because each  node is completely
  154.     different (usually).   But with  a sub-board, parameters  about the  modem,
  155.     etc.,  are  not  needed.    Therefore,  there  is  only  ONE  configuration
  156.     description file for each sub-board.
  157.  
  158.     RBBS-PC will search for a conference .DEF file in THREE  places (and in the
  159.     following order):3
  160.       -  The default drive/path (when RBBS-PC starts)
  161.       -  The location of the CURRENT message base (the one active when the JOIN
  162.          command is used).
  163.       -  Where the CONFERENCE menu file is stored (see CONFIG parameter 74).
  164.  
  165.     Here's an important  tip to  help with sub-boards  functioning on  multiple
  166.     nodes.  CONFIG parameter 90 controls the system callers file.   Select this
  167.     parameter,  and when CONFIG asks  you if you  want to have  a callers file,
  168.     answer "N".   This will cause  the sub-board to use  the same callers  file
  169.     that the  node is currently using.   Since you only  have one configuration
  170.     description  for each sub-board, specifying a callers file in the sub-board
  171.     configuration description file would cause  information from both nodes  to
  172.     be written to the same callers file, and this would be mass confusion.
  173.  
  174.     DOORS
  175.  
  176.     Many  door  programs  (especially  older  ones)  are  simply   not  network
  177.     compatible.   Some of the  doors that you have been  running for years will
  178.     suddenly  not work in a  network.  Each  door is an individual  case.  Some
  179.     doors are  hard-coded to pick  up DORINFO1.DEF and  cannot be made  to read
  180.     DORINFO2.DEF.   Others are  locked into COM1  and cannot be  forced over to
  181.     COM2.   And  still others  force you  to have  DORINFO1.DEF in  a directory
  182.     called "C:\RBBS" and will  refuse to look anywhere else for the possibility
  183.     of a second node's files.
  184.  
  185.     When you have a door which is network compatible, usually the documentation
  186.     that accompanies the program will explain in detail how to install the door
  187.     on your BBS.   In general, a  door program is installed in  one location on
  188.     the  network, and  all  nodes will  run the  door  from that  subdirectory.
  189.     RBBS-PC will create a DORINFOn.DEF,  where "n" is the node number,  when it
  190.     exits to a door.  Almost all door programs want to know where this file is,
  191.     and a variety of options are available to you.  One option often used is to
  192.     set an  environment variable to the  drive letter that will  be the default
  193.     drive for a specific node.
  194.  
  195.  
  196.  
  197.     RBBS-PC 17.3A            TECHNICAL REFERENCE MANUAL                     H-4
  198.  
  199.  
  200.     For example, let's  say that our Node 1  system runs from W:\RBBS,  and our
  201.     Node 2 system runs from Y:\RBBS.  If we set an environment variable in each
  202.     node's AUTOEXEC.BAT  file called RBBS (e.g. SET RBBS=W:), then we can refer
  203.     to the location of the DORINFOn.DEF file as:
  204.  
  205.           "%rbbs%\RBBS\DORINFO%node%.DEF".
  206.  
  207.     (Notice the  use of the %node%  environment variable, also.)   In this way,
  208.     each node running the door will substitute the proper drive and node number
  209.     to the door.
  210.  
  211.     MISCELLANEOUS TRICKS
  212.  
  213.     RBBS-PC is written to share resources with no conflict between  nodes.  For
  214.     example, both nodes will access the same message and user files, and at the
  215.     same time.   Under ordinary DOS circumstances, this would  cause a "sharing
  216.     violation" error.  RBBS-PC, however, accesses files in "shared mode", which
  217.     eliminates  this error.   There are  still times,  however, when  files are
  218.     accessed  outside  the  direct  control  of  RBBS-PC.    To  eliminate  the
  219.     possibility of sharing violation  errors at these times also,  we recommend
  220.     marking all your TEXT, .COM,  .EXE, and .BAT files "read only".   (The read
  221.     only attribute lets DOS  know that it's okay for  more than one process  to
  222.     access this file at the  same time, because NEITHER process will be able to
  223.     modify it.)
  224.  
  225.     To change  a file's attribute,  you will use the  DOS utility ATTRIB.   The
  226.     command syntax is  "ATTRIB +R filespec", where filespec can  be anything up
  227.     to and including "*.*".   Conversely, "ATTRIB -R filespec" will remove  the
  228.     read only attribute so that the file may be changed.
  229.  
  230.     If  you are  operating your  multi-node RBBS-PC  with two  separate RBBS-PC
  231.     subdirectories (i.e. all files duplicated in a second location except those
  232.     which MUST be  shared), then this  precaution is  not needed.   If, on  the
  233.     other hand, you are operating your multi-node RBBS-PC with a SINGLE RBBS-PC
  234.     subdirectory, then we recommend  making all files read-only which  will not
  235.     be written to by RBBS-PC.
  236.  
  237.     Files which will be written  to are the callers files, the user  files, the
  238.     message files and  the upload directory.  Since these  are only opened from
  239.     within  the RBBS-PC  program,  you will  not  have sharing  problems  here.
  240.     (Note:   Some door programs require  access to these dynamic  files, and do
  241.     not support shared access.  This can cause the door program to malfunction.
  242.     This would be considered a door program which is NOT "network-able".)
  243.  
  244.